I would propose to rename notificationComplete to action to keep it in line with all the other events.

The switches already send an action command. We've differentiated notificationComplete because it's the switch itself acknowledging that the notification is done vs the action being something that was performed on a switch (tapping or multi tapping on a button). I don't think it makes sense to try to conflate the two into a single action.

What about action: notification_done? I really don't want to introduce more action like properties (because then more will come)

There's a bunch of different values though, not just one and we need to know which one is returned:

const LED_NOTIFICATION_TYPES: {[key: number]: string} = {
    0: "LED_1",
    1: "LED_2",
    2: "LED_3",
    3: "LED_4",
    4: "LED_5",
    5: "LED_6",
    6: "LED_7",
    16: "ALL_LEDS",
    "-1": "CONFIG_BUTTON_DOUBLE_PRESS",
};

See: https://github.com/Koenkk/zigbee-herdsman-converters/blob/c2ffd92daad72db1a8020391fd7f564de76824f9/src/lib/inovelli.ts#L815

Agreed with the no-more-action-like props decision. It would too quickly become a nightmare for both dev maintenance and user usage patterns.
I haven't looked at the upstream code, but is publishing a "completion" event even necessary?

I haven't looked at the upstream code, but is publishing a "completion" event even necessary?

I'm not 100% familiar with Z2M (I use ZHA), but yes, the switch in question broadcasts that the notification is dismissed through this event. And there are many possible values it passes along with it for combination(s) of LEDs that are no longer being used for the notification.

My understanding is that it'll be much easier to code this if the notificationComplete isn't "stuck" in a truthy state, and that's what the main issue is with how it's currently being delivered via Z2M.

Hopefully this helps and/or @rohankapoorcom or @MrDaGree could better clarify.

I haven't looked at the upstream code, but is publishing a "completion" event even necessary?

If your question is do we need to know whether the notification is complete, yes. @wbyoung made a notification manager for Inovelli switches. It needs to know which notifications that were triggered are still running and the only way to know that is to get the completion event.

If the question is do we need to clear the notification completion event, I believe so. The problem otherwise is that the state becomes "sticky" and the notification manager has no idea what it is referring to when the notification completion doesn't change. Here's an example workflow:

• I set a notification for 10 seconds on LED 7.
• After 10 seconds, the notification completion event triggers and now notificationComplete = "LED_7".
• The notification manager detects the change and knows the notification has completed
• I set another notification for 10 seconds on LED 7.
• After 10 seconds, the notification completion event changes, but notificationComplete doesn't change. It's still set to notificationComplete = "LED_7"
• The notification manager has no way to know the second notification has completed.

Please let me know if you can think of another way to handle this.

Could this maybe be exposed as a binary which goes to true when running and false when getting a notificationComplete?

Could this maybe be exposed as a binary which goes to true when running and false when getting a notificationComplete?

Probably not. The notification complete contains several possible payloads (for ALL_LEDS or LED_1-LED_7 getting completed).

I don't see why that would expose blocking each led as a binary, in case notificationComplete: ALL_LEDS is send, all led binary exposes should go to false.

How would a binary help here? How do they get "reset" and set back to false? Don't we still have the same problem?

• I set a notification for 10 seconds on LED 7.
• After 10 seconds, the notification completion event triggers and now notificationCompleteLed7 = true.
• The notification manager detects the change and knows the notification has completed
• I set another notification for 10 seconds on LED 7.
• After 10 seconds, the notification completion event changes, but notificationComplete doesn't change. It's still set to notificationCompleteLed7 = true
• The notification manager has no way to know the second notification has completed.

If I understand correctly, this will give the following behaviour:

Start situation: led_7 = OFF

I set a notification for 10 seconds on LED 7.

State change: led_7 = ON

After 10 seconds, the notification completion event triggers and now notificationCompleteLed7 = true.

State change: led_7 = OFF

The notification manager detects the change and knows the notification has completed

Can detect the change because led_7 goes from ON to OFF

I set another notification for 10 seconds on LED 7.

State change: led_7 = ON

After 10 seconds, the notification completion event changes, but notificationComplete doesn't change. It's still set to notificationCompleteLed7 = true
The notification manager has no way to know the second notification has completed.

State change: led_7 = ON

Would that solve the issue?

If I understand correctly, this will give the following behaviour:

Start situation: led_7 = OFF

I set a notification for 10 seconds on LED 7.

State change: led_7 = ON

After 10 seconds, the notification completion event triggers and now notificationCompleteLed7 = true.

State change: led_7 = OFF

The notification manager detects the change and knows the notification has completed

Can detect the change because led_7 goes from ON to OFF

I set another notification for 10 seconds on LED 7.

State change: led_7 = ON

After 10 seconds, the notification completion event changes, but notificationComplete doesn't change. It's still set to notificationCompleteLed7 = true
The notification manager has no way to know the second notification has completed.

State change: led_7 = ON

Would that solve the issue?

Maybe. But it's maybe also conflating the state of the LED(s) and the state of the notification. We want just the state of the notification (which may be what you were after, but just using abbreviated names to write it all more quickly).

These switches are a little funny in how they display things:

• It'll show you the base on/off color when no notification is set
• If an ALL_LED notification is active, it'll show that (even if an LED_1 notification is also set)
• If LED_1 is set, it'll show that (unless the ALL_LED is notification set)

So all and individual are mutually exclusive.

If the goal is for Z2M to consider this and try to show the state of active notifications, then it may need to have the same underlying setup. I think the following would need to be the flags (rather than just the on/off state for an individual LED):

• ALL_LED_NOTIFICATION
• LED_1_NOTIFICATION
• LED_2_NOTIFICATION
• LED_3_NOTIFICATION
• LED_4_NOTIFICATION
• LED_5_NOTIFICATION
• LED_6_NOTIFICATION
• LED_7_NOTIFICATION

And then each of those can be on/off.

For reference, here are the values found for the command field that are in the events sent by ZHA.

(Also, in your example above, was the final stage change supposed to be to led_7 = OFF?)

I'm worried that we're basically just introducing a lot of state tracking into Z2M for very little benefit when we have a transient event and just want to pass that transient event along to let the consuming service manage that.

One problem with tracking all of these states is when a switch is rebooted (through a power issue or the air gap being pulled). When the switch powers on again, Z2M would have no way to know that all of the notifications have been reset (and no way to query and find that out). So this state would end up horribly out of sync.

I'm worried that we're basically just introducing a lot of state tracking into Z2M for very little benefit when we have a transient event and just want to pass that transient event along to let the consuming service manage that.

One problem with tracking all of these states is when a switch is rebooted (through a power issue or the air gap being pulled). When the switch powers on again, Z2M would have no way to know that all of the notifications have been reset (and no way to query and find that out). So this state would end up horribly out of sync.

I 100% agree with you here. This is certainly an issue in the integration I'm working on, but that seems like a better place to explain that it's not possible than having Z2M introduce that idea and field all of the support for it. If I decide in my integration (or whatever I'm using Z2M for) that I'm willing to accept the trade-off, then that's on me.

But as a general idea it seems like Z2M should expose an event when the underlying device is emitting an event, and state when the device is reporting to be in a certain state. Specifically in this case there's only the event. There's no way (currently) to query for the state.

Event/action seem interchangeable to me, though again don't know Z2M well. But event/action is what I'd want to consume ideally (not state).

But as a general idea it seems like Z2M should expose an event when the underlying device is emitting an event, and state when the device is reporting to be in a certain state. Specifically in this case there's only the event. There's no way (currently) to query for the state.

Event/action seem interchangeable to me, though again don't know Z2M well. But event/action is what I'd want to consume ideally (not state).

Yeah, I agree. The only way I know besides this PR would be to overload these events into the existing action event which is where all of the user oriented actions (multi tap / scene controls) are controlled from. I really don't like the idea of combining them but I would prefer that to tracking state here.

On the Z-Wave switches this is just exposed as a separate event as well as far as I can tell.